The present invention relates generally to communication systems. More particularly, the present invention relates to speeding up the connect time between communication systems.
56 kbps modems are now standardized in accordance with the ITU V.90 Recommendation. However, many 56 kbps modems, particularly end user modems, may only be compatible with legacy modes such as K56flex, V.34, V.FC, and V.32. Such legacy modems, and downwardly compatible V.90 modems, may have an undesirably long connect or initialization time between dial-up and full rate data mode. The startup time can be up to 30 seconds, which can be rather annoying and unattractive from the perspective of the end user, especially in light of other data communication protocols that appear to operate in an xe2x80x9calways connectedxe2x80x9d manner.
V.90 modems that support legacy modem protocols typically perform the functions shown in Table 1 during initialization. The time periods associated with the operations set forth in Table 1 may vary from connection to connection depending upon various factors such as the server speed and channel conditions.
The V.8bis operation includes a relatively long timeout period that encompasses much of the time period associated with the operation. This operation is described in detail in ITU-T Recommendation V.8bis (International Telecommunication Union, August 1996), the content of which is incorporated by reference herein. The V.8bis protocol is an extension of the V.8 protocol, as described in ITU-T Recommendation V.8 (International Telecommunication Union, February 1998), the content of which is incorporated by reference herein. In accordance with V.8bis and/or V.8, the two modem devices exchange their individual capabilities such that compatible protocols may be utilized during subsequent initialization and data communication procedures.
The various V.90 startup phases are utilized to determine the analog and digital channel characteristics, to train the modem equalizers, and to otherwise attempt to optimize the current communication session. The details of the V.90 startup phases and other aspects of a V.90 modem system may be found in ITU-T Recommendation V.90 (International Telecommunication Union, September 1998), the content of which is incorporated by reference herein. Although a portion of the V.90 startup segments shown in Table 1 are required without regard to the location or status of the client modem, many of the operations could be eliminated or shortened upon repeated connections associated with the same (or nearly identical) channel characteristics.
In a conventional V.90 modem system, error correction and data compression techniques are performed during the V.42/V.42bis stage. The specifics of V.42 are contained in ITU-T Recommendation V.42 (International Telecommunication Union, October 1996), the content of which is incorporated by reference herein. The specifics of V.42bis are contained in ITU-T Recommendation V.42bis (International Telecommunication Union, January 1990), the content of which is incorporated by reference herein. The V.42 operation is desirable such that the modem system can perform the login procedure in a substantially xe2x80x9cerror freexe2x80x9d mode. The login procedure may be conducted with CHAP and PAP protocols; both are utilized for security purposes in the context of point-to-point protocol (xe2x80x9cPPPxe2x80x9d) connections, e.g., a connection between a client computer and an internet service provider server. From the perspective of the V.90 modem devices, the login information is transmitted as data. Once the login procedure is performed, the dial-up connection is complete and data may be transmitted between the server and the host software associated with the client.
The widespread use of the internet as a daily research, entertainment, and communication tool has increased the deployment of 56 kbps modems. However, many channels can only support legacy modes such as V.34. Thus, although most newer modems (particularly those sold with new personal computers) are compatible with the V.90 Recommendation, many legacy modes are still in use. The long initialization period associated with V.90 modems that fall back into legacy modes may be annoying and undesirable in many applications and can be a serious hindrance where a user would like to establish an immediate connection after an unanticipated disconnect. In addition, even in the context of a connection between two V.90 modem devices, the long V.90 startup phases may test the mettle of an impatient end user. Accordingly, it would be highly desirable to reduce the initialization time normally associated with a conventional V.90 modem system.
A given modem communication session may be interrupted or disconnected for any number of reasons. For example, a call waiting signal may disrupt a modem connection to the extent that the modem call must either be reconnected or reinitialized. As another example, it may be possible to place a current modem connection on hold to enable the user to answer an incoming call in response to a call waiting signal or to enable the user to place an outgoing call without disconnecting the modem connection. Ideally, the modem connection could be re-established in an instantaneous manner. However, in a practical system, a retraining or reinitialization procedure must be carried out to ensure that the two end devices are properly synchronized and to ensure that the channel is adequately equalized. As discussed above, conventional V.90 modem systems may spend more than 20 seconds during such retraining and reinitialization. Accordingly, it would also be desirable to reduce the reconnection time between the same modem devices in response to a temporary disconnect or a temporary pause in the data communication.
One major time consuming portion of modem training and negotiation occurs during parameter exchanges, such as exchange of data signaling rate, precoding coefficient, spectral shaping, constellation information and etc. With reference to FIG. 5, it is shown that, for example, during V.90 negotiations, an analog pulse code modulation (xe2x80x9cAPCMxe2x80x9d) modem 580 transmits a constellation parameter (xe2x80x9cCPxe2x80x9d) frame 510 to a digital pulse code modulation (xe2x80x9cDPSMxe2x80x9d) modem 590 that, in-exchange, transmits a modulation parameter (xe2x80x9cMPxe2x80x9d) frame 520 to the APCM modem 580. The MP frame 520 and the CP frame 510 are in synchronous form and include many bits of information and CRC information for error checking purposes (see FIGS. 17 and 18), as further described below.
As shown in FIG. 5, the APCM modem 580 continuously transmits CP frames 510 to the DPCM modem 590 until the APCM modem 580 receives a receipt acknowledgement from the DPCM modem 590 for one of the transmitted CP frames 510. Similarly, the DPCM modem 590 continuously transmits MP frames 520 to the APCM modem 580 until the DPCM modem 590 receives a receipt acknowledgement from the APCM modem 580 for one of the transmitted MP frames 520.
The receipt acknowledgement for the CP frame 510 is transmitted in the form of an MP frame 520, including each and every bit of information and having the acknowledgement bit 33 of the MP frame 520 set to a xe2x80x9c1xe2x80x9d. The MP frame 520 having its acknowledgement bit 33 set to a xe2x80x9c1xe2x80x9d is denoted as MPxe2x80x2 frame 522. Once the DPCM modem 590 receives a CP frame 510, the DPCM modem 590 starts transmitting the MPxe2x80x2 frames 522 instead of the MP frames 520. This repeated transmission of MPxe2x80x2 frames 522 continues until the DPCM modem 590 receives a receipt acknowledgement for the MP or MPxe2x80x2 frames 520 or 522.
Similar to the DPCM modem 590, the receipt acknowledgement from the APCM modem 580 is transmitted in the form of a CP frame 510, including each and every bit of information and having the acknowledgement bit 33 of the CP frame 510 set to a xe2x80x9c1xe2x80x9d. The CP frame 510 having its acknowledgement bit 33 set to a xe2x80x9c1xe2x80x9d is denoted as CPxe2x80x2 frame 512. Once the APCM modem 580 receives an MP frame 520, the APCM modem 580 starts transmitting the CPxe2x80x2 frames 512 instead of the CP frames 510. This repeated transmission of CPxe2x80x2 frames 512 continues until the APCM modem 580 receives a receipt acknowledgement for the CP or CPxe2x80x2 frames 510 or 512.
The repeated transmissions of these long CP, CPxe2x80x2, MP and MPxe2x80x2 frames, including many bits of information, are indeed a tremendous overhead. This problem, however, gets even more exuberated in the next generation of standards, such as the ITU V.92 Recommendation, as more parameters and bits of information must be exchanged between the modems. FIG. 19 shows an example of the V.92 constellation parameter frame for the APCM modem 580 referred to as CPa frame 1900. As seen, the CPa frame includes many more bits of information than the CP and MP frames 1800 and 1900 (see FIGS. 17, 18 and 19), such as the constellation information with high resolution as well as precoder and prefilter coefficients. The CPa frame 1900 further includes variable length parameters, such as parameter 1920, that can potentially add many more bits of information to the CPa frame 1900. Concerns have been raised that because of the acknowledgement mechanism introduced in the ITU Recommendation V.34 and re-used in the ITU Recommendation V.90, the startup time may be unduly increased for the ITU Recommendation V.92, due to these long sequences. For example, during a V.92 PCM upstream startup, a significant amount of information needs to be exchanged between the DPCM modem 590 and the APCM modems 580. In particular, the DPCM modem 590 needs to transmit very long sequences, including constellation information with high resolution as well as precoder and prefilter coefficients in the CPa frames.
Accordingly, there is an intense need in the art to eliminate the tremendous overhead of repeatedly transmitting these very long sequences, including many parameters and bits of information, thereby reducing the training and negotiation time and achieving a quick connect.
The present invention provides techniques to shorten the startup and reconnection times associated with a data communication system that employs a modem. The quick reconnect technique leverages the known channel characteristics of a previous connection to reduce the reinitialization period associated with subsequent attempts to reconnect the same two modem devices. In accordance with one illustrative embodiment, the techniques of the present invention are utilized to reduce the reconnection time for a communication session that follows an upper layer protocol, e.g., PPP. Although not limited to any specific modem application, the quick startup and reconnect procedures may be used to eliminate portions of the initialization protocols or processes normally employed by a V.90 modem, e.g., V.8bis, V.8, digital impairment learning, initial training, probing and ranging, or the like. In addition, the quick startup and reconnect techniques may perform certain operations at a different time or in a different order in comparison to a conventional modem startup technique.
The above and other aspects of the present invention may be carried out in one form by a method for reducing the reconnection time associated with a data transmission system having a first device configured to communicate with a second device over a communication channel. The illustrative method involves establishing a communication session between the first device and the second device over the communication channel, obtaining a number of operating parameters for the data transmission system, where the operating parameters are associated with the communication channel, and storing at least one of the operating parameters at the second device. After a temporary pause in the communication session, the operating parameters are recalled at the second device.
According to one aspect of the present invention, during the startup, retrain, renegotiation, quick connect or other handshaking processes between the communication systems, the communication systems exchange a number of parameters such as modulation, constellation, precoder, prefilter and other communication related information. The communication systems exchange one long information sequence including all necessary parameters or communication information. Subsequently, the communication systems start transmitting short sequences, including an acknowledgement information portion, but not all the other parameters or information embedded in the long sequences. Once each communication system receives a short sequence with the acknowledgment information indicating receipt of the long information sequence, the communication systems may move on to the next stage of the handshaking process. The use of short information sequences substantially shortens the handshaking process and eliminates the delay and overhead introduced by continuous transmissions and retransmissions of the long information sequences.
In yet another aspect of the present invention, if one of the communication systems does not receive an acknowledgement sequence within a predetermined time or event, that communication system may retransmit another long information sequence. Subsequently, the retransmitting communication system may continue transmitting the long information sequences or may start transmitting the short sequences once again.
These and other aspects of the present invention will become apparent with further reference to the drawings and specification, which follow.